Что нового в WebGPU (Chrome 133)

Франсуа Бофор
François Beaufort

Опубликовано: 29 января 2025 г.

Дополнительные форматы вершин unorm8x4-bgra и 1-компонентные

Добавлены формат вершин "unorm8x4-bgra" и следующие форматы вершин с 1 компонентом: "uint8" , "sint8" , "unorm8" , "snorm8" , "uint16" , "sint16" , "unorm16" ", "snorm16" и "float16" . Формат вершин "unorm8x4-bgra" делает загрузку цветов вершин, закодированных в BGRA, немного более удобной, сохраняя при этом тот же шейдер. Кроме того, формат вершин с 1 компонентом позволяет запрашивать только необходимые данные, тогда как ранее для 8- и 16-битных типов данных требовалось как минимум вдвое больше. См. запись chromestatus и проблему 376924407 .

Разрешить запрашивать неизвестные лимиты с неопределенным значением

Чтобы сделать API WebGPU менее хрупким по мере его развития, теперь вы можете запрашивать неизвестные лимиты с undefined значением при запросе устройства GPU. Это полезно в следующем коде приложения, например, где adapter.limits.someLimit может быть undefined если someLimit больше не существует. См. спецификацию PR 4781 .

const adapter = await navigator.gpu.requestAdapter();

const device = await adapter.requestDevice({
  requiredLimits: { someLimit: adapter.limits.someLimit }, // someLimit can be undefined
});

Изменения правил выравнивания WGSL

Больше невозможно указать слишком маленькое значение выравнивания для члена структуры, поскольку теперь требуется, чтобы @align(n) делил RequiredAlignOf для всех структур. Это критическое изменение упрощает использование языка WGSL и делает его более совместимым с Firefox и Safari. Вы можете найти пример кода, показывающий различия между компиляторами Tint, Naga и WebKit, в спецификации PR .

Повышение производительности WGSL с отбрасыванием

Из-за значительного падения производительности, наблюдаемого при рендеринге сложного эффекта отражений в экранном пространстве (SSR), реализация оператора discard использует предоставляемую платформой семантику для понижения до вызова помощника, когда это доступно. Это повышает производительность шейдеров, использующих discard. См. issue 372714384 .

Используйте VideoFrame displaySize для внешних текстур

Размеры displayWidth и displayHeight должны использоваться как видимый размер GPUExternalTexture при импорте VideoFrame в соответствии со спецификацией WebGPU. Однако видимый размер использовался неправильно, что приводило к проблемам при попытке использования textureLoad() на GPUExternalTexture. Теперь это исправлено. См. issue 377574981 .

Обработка изображений с ориентацией, отличной от стандартной, с помощью copyExternalImageToTexture

Метод copyExternalImageToTexture() GPUQueue используется для копирования содержимого изображения или холста в текстуру. Теперь он правильно обрабатывает изображения с ориентацией, отличной от стандартной. Раньше это было не так, когда источником был ImageBitmap с imageOrientation "from-image" или изображение с ориентацией, отличной от стандартной. См. issue 384858956 .

Улучшение опыта разработчиков

Может быть удивительно, когда adapter.limits показывает высокие значения, но вы не понимаете, что вам нужно явно запросить более высокий лимит при запросе устройства GPU. Невыполнение этого требования может привести к неожиданному достижению лимитов в дальнейшем.

Чтобы помочь вам, сообщения об ошибках были расширены подсказками, которые говорят вам явно запросить более высокий лимит, если при вызове requestDevice() в requiredLimits не был указан лимит. См. проблему 42240683 .

В следующем примере показано улучшенное сообщение об ошибке, регистрируемое в консоли DevTools при создании буфера графического процессора, размер которого превышает максимальный размер буфера устройства по умолчанию.

const adapter = await navigator.gpu.requestAdapter();
const device = await adapter.requestDevice();

// Create a GPU buffer with a size exceeding the default max buffer size device limit.
const size = device.limits.maxBufferSize + 1;
const buffer = device.createBuffer({ size, usage: GPUBufferUsage.MAP_READ });

device.queue.submit([]);
⚠️ Buffer size (268435457) exceeds the max buffer size limit (268435456). This adapter supports a higher maxBufferSize of 4294967296, which can be specified in requiredLimits when calling requestDevice(). Limits differ by hardware, so always check the adapter limits prior to requesting a higher limit.
- While calling [Device].CreateBuffer([BufferDescriptor]).

Включить режим совместимости с featureLevel

Запрос адаптера GPU в экспериментальном режиме совместимости теперь возможен путем установки стандартизированной опции featureLevel на "compatibility" . Строки "core" (по умолчанию) и "compatibility" являются единственными допустимыми значениями. См. следующий пример и спецификацию PR 4897 .

// Request a GPU adapter in compatibility mode
const adapter = await navigator.gpu.requestAdapter({ featureLevel: "compatibility" });

if (adapter?.featureLevel === "compatibility") {
  // Any devices created from this adapter will support only compatibility mode.
}

Параметр featureLevel заменяет нестандартный параметр compatibilityMode , а нестандартный атрибут featureLevel заменяет атрибут isCompatibilityMode .

Поскольку это все еще экспериментальный вариант, вам нужно запустить Chrome с флагом "Unsafe WebGPU Support" на chrome://flags/#enable-unsafe-webgpu на данный момент. Проверьте webgpureport.org , чтобы поиграться с ним.

Экспериментальная подгруппа функций очистки

Устаревшие функции экспериментальной подгруппы "chromium-experimental-subgroups" и "chromium-experimental-subgroup-uniform-control-flow" удалены. См. issue 377868468 .

Экспериментальная функция "subgroups" — это все, что вам нужно сейчас при экспериментах с подгруппами . Экспериментальная функция "subgroups-f16" устарела и скоро будет удалена. Вы можете использовать значения f16 с подгруппами, когда ваше приложение запрашивает обе функции "shader-f16" и "subgroups" . См. issue 380244620 .

Отменить ограничение maxInterStageShaderComponents

Ограничение maxInterStageShaderComponents устарело из-за ряда факторов:

  • Избыточность с maxInterStageShaderVariables : это ограничение уже выполняет аналогичную функцию, контролируя объем данных, передаваемых между этапами шейдера.
  • Незначительные расхождения: хотя существуют небольшие различия в том, как рассчитываются эти два предела, эти различия незначительны и ими можно эффективно управлять в пределах предела maxInterStageShaderVariables .
  • Упрощение: удаление maxInterStageShaderComponents упрощает интерфейс шейдера и снижает сложность для разработчиков. Вместо того, чтобы управлять двумя отдельными ограничениями с тонкими различиями, они могут сосредоточиться на более подходящем названии и всеобъемлющем maxInterStageShaderVariables .

Цель — полностью удалить его в Chrome 135. См. намерение прекратить поддержку и выпуск 364338810 .

Обновления рассвета

wgpu::Device::GetAdapterInfo(adapterInfo) позволяет вам получать информацию об адаптере напрямую из wgpu::Device . См. issue 376600838 .

Структура WGPUProgrammableStageDescriptor была переименована в WGPUComputeState , чтобы состояние вычислений соответствовало состояниям вершин и фрагментов. См. issue 379059434 .

Значение перечисления wgpu::VertexStepMode::VertexBufferNotUsed было удалено. Макет буфера вершин, который не используется, теперь можно выразить с помощью {.stepMode=wgpu::VertexStepMode::Undefined, .attributeCount=0} . См. issue 383147017 .

Это охватывает только некоторые из ключевых моментов. Ознакомьтесь с исчерпывающим списком коммитов .

Что нового в WebGPU

Список всего, что было рассмотрено в серии « Что нового в WebGPU» .

Хром 137

Хром 136

Хром 135

Хром 134

Хром 133

Хром 132

Хром 131

Хром 130

Хром 129

Хром 128

Хром 127

Хром 126

Хром 125

Хром 124

Хром 123

Хром 122

Хром 121

Хром 120

Хром 119

Хром 118

Хром 117

Хром 116

Хром 115

Хром 114

Хром 113

,

Франсуа Бофор
François Beaufort

Опубликовано: 29 января 2025 г.

Дополнительные форматы вершин unorm8x4-bgra и 1-компонентные

Добавлены формат вершин "unorm8x4-bgra" и следующие форматы вершин с 1 компонентом: "uint8" , "sint8" , "unorm8" , "snorm8" , "uint16" , "sint16" , "unorm16" ", "snorm16" и "float16" . Формат вершин "unorm8x4-bgra" делает загрузку цветов вершин, закодированных в BGRA, немного более удобной, сохраняя при этом тот же шейдер. Кроме того, формат вершин с 1 компонентом позволяет запрашивать только необходимые данные, тогда как ранее для 8- и 16-битных типов данных требовалось как минимум вдвое больше. См. запись chromestatus и проблему 376924407 .

Разрешить запрашивать неизвестные лимиты с неопределенным значением

Чтобы сделать API WebGPU менее хрупким по мере его развития, теперь вы можете запрашивать неизвестные лимиты с undefined значением при запросе устройства GPU. Это полезно в следующем коде приложения, например, где adapter.limits.someLimit может быть undefined если someLimit больше не существует. См. спецификацию PR 4781 .

const adapter = await navigator.gpu.requestAdapter();

const device = await adapter.requestDevice({
  requiredLimits: { someLimit: adapter.limits.someLimit }, // someLimit can be undefined
});

Изменения правил выравнивания WGSL

Больше невозможно указать слишком маленькое значение выравнивания для члена структуры, поскольку теперь требуется, чтобы @align(n) делил RequiredAlignOf для всех структур. Это критическое изменение упрощает использование языка WGSL и делает его более совместимым с Firefox и Safari. Вы можете найти пример кода, показывающий различия между компиляторами Tint, Naga и WebKit, в спецификации PR .

Повышение производительности WGSL с отбрасыванием

Из-за значительного падения производительности, наблюдаемого при рендеринге сложного эффекта отражений в экранном пространстве (SSR), реализация оператора discard использует предоставляемую платформой семантику для понижения до вызова помощника, когда это доступно. Это повышает производительность шейдеров, использующих discard. См. issue 372714384 .

Используйте VideoFrame displaySize для внешних текстур

Размеры displayWidth и displayHeight должны использоваться как видимый размер GPUExternalTexture при импорте VideoFrame в соответствии со спецификацией WebGPU. Однако видимый размер использовался неправильно, что приводило к проблемам при попытке использования textureLoad() на GPUExternalTexture. Теперь это исправлено. См. issue 377574981 .

Обработка изображений с ориентацией, отличной от стандартной, с помощью copyExternalImageToTexture

Метод copyExternalImageToTexture() GPUQueue используется для копирования содержимого изображения или холста в текстуру. Теперь он правильно обрабатывает изображения с ориентацией, отличной от стандартной. Раньше это было не так, когда источником был ImageBitmap с imageOrientation "from-image" или изображение с ориентацией, отличной от стандартной. См. issue 384858956 .

Улучшение опыта разработчиков

Может быть удивительно, когда adapter.limits показывает высокие значения, но вы не понимаете, что вам нужно явно запросить более высокий лимит при запросе устройства GPU. Невыполнение этого требования может привести к неожиданному достижению лимитов в дальнейшем.

Чтобы помочь вам, сообщения об ошибках были расширены подсказками, которые говорят вам явно запросить более высокий лимит, если при вызове requestDevice() в requiredLimits не был указан лимит. См. проблему 42240683 .

В следующем примере показано улучшенное сообщение об ошибке, регистрируемое в консоли DevTools при создании буфера графического процессора, размер которого превышает максимальный размер буфера устройства по умолчанию.

const adapter = await navigator.gpu.requestAdapter();
const device = await adapter.requestDevice();

// Create a GPU buffer with a size exceeding the default max buffer size device limit.
const size = device.limits.maxBufferSize + 1;
const buffer = device.createBuffer({ size, usage: GPUBufferUsage.MAP_READ });

device.queue.submit([]);
⚠️ Buffer size (268435457) exceeds the max buffer size limit (268435456). This adapter supports a higher maxBufferSize of 4294967296, which can be specified in requiredLimits when calling requestDevice(). Limits differ by hardware, so always check the adapter limits prior to requesting a higher limit.
- While calling [Device].CreateBuffer([BufferDescriptor]).

Включить режим совместимости с featureLevel

Запрос адаптера GPU в экспериментальном режиме совместимости теперь возможен путем установки стандартизированной опции featureLevel на "compatibility" . Строки "core" (по умолчанию) и "compatibility" являются единственными допустимыми значениями. См. следующий пример и спецификацию PR 4897 .

// Request a GPU adapter in compatibility mode
const adapter = await navigator.gpu.requestAdapter({ featureLevel: "compatibility" });

if (adapter?.featureLevel === "compatibility") {
  // Any devices created from this adapter will support only compatibility mode.
}

Параметр featureLevel заменяет нестандартный параметр compatibilityMode , а нестандартный атрибут featureLevel заменяет атрибут isCompatibilityMode .

Поскольку это все еще экспериментальный вариант, вам нужно запустить Chrome с флагом "Unsafe WebGPU Support" на chrome://flags/#enable-unsafe-webgpu на данный момент. Проверьте webgpureport.org , чтобы поиграться с ним.

Экспериментальная подгруппа функций очистки

Устаревшие функции экспериментальной подгруппы "chromium-experimental-subgroups" и "chromium-experimental-subgroup-uniform-control-flow" удалены. См. issue 377868468 .

Экспериментальная функция "subgroups" — это все, что вам нужно сейчас при экспериментах с подгруппами . Экспериментальная функция "subgroups-f16" устарела и скоро будет удалена. Вы можете использовать значения f16 с подгруппами, когда ваше приложение запрашивает обе функции "shader-f16" и "subgroups" . См. issue 380244620 .

Отменить ограничение maxInterStageShaderComponents

Ограничение maxInterStageShaderComponents устарело из-за ряда факторов:

  • Избыточность с maxInterStageShaderVariables : это ограничение уже выполняет аналогичную функцию, контролируя объем данных, передаваемых между этапами шейдера.
  • Незначительные расхождения: хотя существуют небольшие различия в том, как рассчитываются эти два предела, эти различия незначительны и ими можно эффективно управлять в пределах предела maxInterStageShaderVariables .
  • Упрощение: удаление maxInterStageShaderComponents упрощает интерфейс шейдера и снижает сложность для разработчиков. Вместо того, чтобы управлять двумя отдельными ограничениями с тонкими различиями, они могут сосредоточиться на более подходящем названии и всеобъемлющем maxInterStageShaderVariables .

Цель — полностью удалить его в Chrome 135. См. намерение прекратить поддержку и выпуск 364338810 .

Обновления рассвета

wgpu::Device::GetAdapterInfo(adapterInfo) позволяет вам получать информацию об адаптере напрямую из wgpu::Device . См. issue 376600838 .

Структура WGPUProgrammableStageDescriptor была переименована в WGPUComputeState , чтобы состояние вычислений соответствовало состояниям вершин и фрагментов. См. issue 379059434 .

Значение перечисления wgpu::VertexStepMode::VertexBufferNotUsed было удалено. Макет буфера вершин, который не используется, теперь можно выразить с помощью {.stepMode=wgpu::VertexStepMode::Undefined, .attributeCount=0} . См. issue 383147017 .

Это охватывает только некоторые из ключевых моментов. Ознакомьтесь с исчерпывающим списком коммитов .

Что нового в WebGPU

Список всего, что было рассмотрено в серии « Что нового в WebGPU» .

Хром 137

Хром 136

Хром 135

Хром 134

Хром 133

Хром 132

Хром 131

Хром 130

Хром 129

Хром 128

Хром 127

Хром 126

Хром 125

Хром 124

Хром 123

Хром 122

Хром 121

Хром 120

Хром 119

Хром 118

Хром 117

Хром 116

Хром 115

Хром 114

Хром 113

,

Франсуа Бофор
François Beaufort

Опубликовано: 29 января 2025 г.

Дополнительные форматы вершин unorm8x4-bgra и 1-компонентные

Добавлены формат вершин "unorm8x4-bgra" и следующие форматы вершин с 1 компонентом: "uint8" , "sint8" , "unorm8" , "snorm8" , "uint16" , "sint16" , "unorm16" ", "snorm16" и "float16" . Формат вершин "unorm8x4-bgra" делает загрузку цветов вершин, закодированных в BGRA, немного более удобной, сохраняя при этом тот же шейдер. Кроме того, формат вершин с 1 компонентом позволяет запрашивать только необходимые данные, тогда как ранее для 8- и 16-битных типов данных требовалось как минимум вдвое больше. См. запись chromestatus и проблему 376924407 .

Разрешить запрашивать неизвестные лимиты с неопределенным значением

Чтобы сделать API WebGPU менее хрупким по мере его развития, теперь вы можете запрашивать неизвестные лимиты с undefined значением при запросе устройства GPU. Это полезно в следующем коде приложения, например, где adapter.limits.someLimit может быть undefined если someLimit больше не существует. См. спецификацию PR 4781 .

const adapter = await navigator.gpu.requestAdapter();

const device = await adapter.requestDevice({
  requiredLimits: { someLimit: adapter.limits.someLimit }, // someLimit can be undefined
});

Изменения правил выравнивания WGSL

Больше невозможно указать слишком маленькое значение выравнивания для члена структуры, поскольку теперь требуется, чтобы @align(n) делил RequiredAlignOf для всех структур. Это критическое изменение упрощает использование языка WGSL и делает его более совместимым с Firefox и Safari. Вы можете найти пример кода, показывающий различия между компиляторами Tint, Naga и WebKit, в спецификации PR .

Повышение производительности WGSL с отбрасыванием

Из-за значительного падения производительности, наблюдаемого при рендеринге сложного эффекта отражений в экранном пространстве (SSR), реализация оператора discard использует предоставляемую платформой семантику для понижения до вызова помощника, когда это доступно. Это повышает производительность шейдеров, использующих discard. См. issue 372714384 .

Используйте VideoFrame displaySize для внешних текстур

Размеры displayWidth и displayHeight должны использоваться как видимый размер GPUExternalTexture при импорте VideoFrame в соответствии со спецификацией WebGPU. Однако видимый размер использовался неправильно, что приводило к проблемам при попытке использования textureLoad() на GPUExternalTexture. Теперь это исправлено. См. issue 377574981 .

Обработка изображений с ориентацией, отличной от стандартной, с помощью copyExternalImageToTexture

Метод copyExternalImageToTexture() GPUQueue используется для копирования содержимого изображения или холста в текстуру. Теперь он правильно обрабатывает изображения с ориентацией, отличной от стандартной. Раньше это было не так, когда источником был ImageBitmap с imageOrientation "from-image" или изображение с ориентацией, отличной от стандартной. См. issue 384858956 .

Улучшение опыта разработчиков

Может быть удивительно, когда adapter.limits показывает высокие значения, но вы не понимаете, что вам нужно явно запросить более высокий лимит при запросе устройства GPU. Невыполнение этого требования может привести к неожиданному достижению лимитов в дальнейшем.

Чтобы помочь вам, сообщения об ошибках были расширены подсказками, которые говорят вам явно запросить более высокий лимит, если при вызове requestDevice() в requiredLimits не был указан лимит. См. проблему 42240683 .

В следующем примере показано улучшенное сообщение об ошибке, регистрируемое в консоли DevTools при создании буфера графического процессора, размер которого превышает максимальный размер буфера устройства по умолчанию.

const adapter = await navigator.gpu.requestAdapter();
const device = await adapter.requestDevice();

// Create a GPU buffer with a size exceeding the default max buffer size device limit.
const size = device.limits.maxBufferSize + 1;
const buffer = device.createBuffer({ size, usage: GPUBufferUsage.MAP_READ });

device.queue.submit([]);
⚠️ Buffer size (268435457) exceeds the max buffer size limit (268435456). This adapter supports a higher maxBufferSize of 4294967296, which can be specified in requiredLimits when calling requestDevice(). Limits differ by hardware, so always check the adapter limits prior to requesting a higher limit.
- While calling [Device].CreateBuffer([BufferDescriptor]).

Включить режим совместимости с featureLevel

Запрос адаптера GPU в экспериментальном режиме совместимости теперь возможен путем установки стандартизированной опции featureLevel на "compatibility" . Строки "core" (по умолчанию) и "compatibility" являются единственными допустимыми значениями. См. следующий пример и спецификацию PR 4897 .

// Request a GPU adapter in compatibility mode
const adapter = await navigator.gpu.requestAdapter({ featureLevel: "compatibility" });

if (adapter?.featureLevel === "compatibility") {
  // Any devices created from this adapter will support only compatibility mode.
}

Параметр featureLevel заменяет нестандартный параметр compatibilityMode , а нестандартный атрибут featureLevel заменяет атрибут isCompatibilityMode .

Поскольку это все еще экспериментальный вариант, вам нужно запустить Chrome с флагом "Unsafe WebGPU Support" на chrome://flags/#enable-unsafe-webgpu на данный момент. Проверьте webgpureport.org , чтобы поиграться с ним.

Экспериментальная подгруппа функций очистки

Устаревшие функции экспериментальной подгруппы "chromium-experimental-subgroups" и "chromium-experimental-subgroup-uniform-control-flow" удалены. См. issue 377868468 .

Экспериментальная функция "subgroups" — это все, что вам нужно сейчас при экспериментах с подгруппами . Экспериментальная функция "subgroups-f16" устарела и скоро будет удалена. Вы можете использовать значения f16 с подгруппами, когда ваше приложение запрашивает обе функции "shader-f16" и "subgroups" . См. issue 380244620 .

Отменить ограничение maxInterStageShaderComponents

Ограничение maxInterStageShaderComponents устарело из-за ряда факторов:

  • Избыточность с maxInterStageShaderVariables : это ограничение уже выполняет аналогичную функцию, контролируя объем данных, передаваемых между этапами шейдера.
  • Незначительные расхождения: хотя существуют небольшие различия в том, как рассчитываются эти два предела, эти различия незначительны и ими можно эффективно управлять в пределах предела maxInterStageShaderVariables .
  • Упрощение: удаление maxInterStageShaderComponents упрощает интерфейс шейдера и снижает сложность для разработчиков. Вместо того, чтобы управлять двумя отдельными ограничениями с тонкими различиями, они могут сосредоточиться на более подходящем названии и всеобъемлющем maxInterStageShaderVariables .

Цель — полностью удалить его в Chrome 135. См. намерение прекратить поддержку и выпуск 364338810 .

Обновления рассвета

wgpu::Device::GetAdapterInfo(adapterInfo) позволяет вам получать информацию об адаптере напрямую из wgpu::Device . См. issue 376600838 .

Структура WGPUProgrammableStageDescriptor была переименована в WGPUComputeState , чтобы состояние вычислений соответствовало состояниям вершин и фрагментов. См. issue 379059434 .

Значение перечисления wgpu::VertexStepMode::VertexBufferNotUsed было удалено. Макет буфера вершин, который не используется, теперь можно выразить с помощью {.stepMode=wgpu::VertexStepMode::Undefined, .attributeCount=0} . См. issue 383147017 .

Это охватывает только некоторые из ключевых моментов. Ознакомьтесь с исчерпывающим списком коммитов .

Что нового в WebGPU

Список всего, что было рассмотрено в серии « Что нового в WebGPU» .

Хром 137

Хром 136

Хром 135

Хром 134

Хром 133

Хром 132

Хром 131

Хром 130

Хром 129

Хром 128

Хром 127

Хром 126

Хром 125

Хром 124

Хром 123

Хром 122

Хром 121

Хром 120

Хром 119

Хром 118

Хром 117

Хром 116

Хром 115

Хром 114

Хром 113